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Acronyms and Nomenclature 


2D: 

2 dimensional; longitudinal and lateral 

4D: 

4 dimensional; longitudinal, lateral, vertical, and temporal 

ADS-B: 

Automatic Dependence Surveillance Broadcast 

ASTAR: 

Airborne Spacing for Terminal Arrival Routes 

ATC: 

Air Traffic Control 

ATD-1: 

Air Traffic Management Technology Demonstration- 1 

CAS: 

Calibrated airspeed 

DTG: 

Distance-to-go 

End speed command: 

Estimated speed command at the end of a speed change 

ETA: 

Estimated time of arrival 

FAF: 

Final approach fix 

FMS: 

Flight Management System 

ft: 

foot/feet 

gs: 

Ground speed 

IAS: 

Indicated airspeed 

kt: 

Knots 

nmi: 

Nautical miles 

Ownship: 

In this document, ownship refers to the aircraft that is performing the operation 

RTA: 

Required time of arrival 

Speed command: 

The continuous, instantaneous speed command provided by the algorithm 

STAR: 

Standard Terminal Arrival Route 

TCP: 

Trajectory change point 

TOD: 

Top-of-descent 
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TTF: 

TTG: 


Traffic to follow; the aircraft against which the spacing aircraft is performing a 
spacing operation 

Time-to-go 
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Abstract 


This paper presents an overview of the fourth revision to an algorithm 
specifically designed to support NASA's Airborne Precision Spacing 
concept. This algorithm is referred to as the Airborne Spacing for 
Terminal Arrival Routes version 11 (ASTAR11). This airborne self- 
spacing concept is trajectory-based, allowing for spacing operations 
prior to the aircraft being on a common path. Because this algorithm is 
trajectory-based, it also has the inherent ability to support required- 
time-of-arrival (RTA) operations. This algorithm was also designed 
specifically to support a standalone, non-integrated implementation in 
the spacing aircraft. Revisions to this algorithm were based on a change 
to the expected operational environment. 

Introduction 

Concepts for self-spacing of aircraft operating in an airport terminal area have been under development 
by the National Aeronautics and Space Administration (NASA) since the 1970 ? s (ref 1). Interest in these 
concepts have recently been renewed due to a combination of emerging, enabling technology (Automatic 
Dependent Surveillance Broadcast data link, ADS-B) and the continued growth in air traffic with the ever 
increasing demand on airport and runway throughput. Terminal area self-spacing has the po tential to 
provide an increase in runway capacity through an increase in the accuracy of over-the-threshold runway 
crossing times (ref 2). 

A follow-on to N ASA's terminal area in-trail spacing development (refs. 3 and 4) and the initial 
development of a cone ept and im plementation fora trajectory-based merging capability (ref. 5) was 
instantiated in an ap plication called the Airborne Spacing for Terminal Arrival Routes, A STAR. This 
concept extended the self-spacing capability beyond the terminal area to a p oint prior to the top of the 
en route descent. This implementation was a totally trajectory based concept for the entire arrival spacing 
operation. The seco nd revised implementation of thi s algorithm (ref. 6) was designed to su pport 
dependent runway operations and was referred to as ASTAR10. This second revision provided the ability 
to manage spacing against two traffic aircraft, with one of these aircraft operating to a parallel runway. 
This support for parallel dependent runway operations also included the computation of offset threshold 
crossing times based on the longitudinal distance offset between the two parallel runways and the ability 
to use diagonal distance spacing once the aircraft are on parallel approaches (ref. 7). This second revision 
of ASTAR also had a rewritten control law relative to the previous version that was based on the original 
Advanced Terminal Area Approach Spacing (ATAAS) algorithm (ref. 3). The third revision of ASTAR, 
referred to as ASTAR11 (ref. 8), is a "lite" version of ASTAR10. In this revision, the ability to space 
against a second aircraft that is operating to a dependent runway has been removed. Additionally, several 
implementation improvements have been made based on observations from a pilot-in-the-loop simulation 
using ASTAR10. 

This current, fourth revision of ASTAR is an update to ASTAR11. In this revision, the primary focus 
was to modify ASTAR to better support the flight deck interval management portion of the Air Traffic 
Management Technology Demonstration- 1 (ATD-1) (ref. 9). Part of this modification included a change 
to the basic control law and the ability to recalculate an aircraft's vertical path if that aircraft is off of its 
preplanned vertical path. 

As with the previous versions of ASTAR, the overall concept for a trajectory-based solution for 
en route and terminal area self-spacing is fairly straightforward. If the 4D trajectory of an aircraft and its 
position are known, then the aircraft's position on its trajectory canbede termined. By knowing the 


aircraft's position on its trajectory, the aircraft’s estimated time-to-go (TTG) to a point, where in the case 
of ASTAR1 1 is typically the runway threshold, is known. To apply this to a self-spacing concept, a TTG 
is calculated for both the traffic to follow aircraft (TTF) and for the ownship, noting that the trajectories 
do not need to be the same. The nominal spacing time, t nom inai, and the spacing time error, t err or, can then be 
calculated as: 


t nominal = TTG T tf + planned spacing time , 


terror TTG ownship t nom i na i , 


where the identification of the TTF aircraft and the determination of the planned spacing time is 
performed by ATC. 


A required time of arrival (RTA) capability can also be implemented in a manner similar to the traffic 
spacing technique. In this case, 


tnominai = RTA - current time. 


From terror, a speed error value can then be calculated. A conceptual example for the determination of 
terror for traffic spacing, i.e., t error = TTG ownship - t nomina i , is shown in figure 1. 



By design, ASTAR1 1 is considered an achieve-by algorithm (ref. 10), i.e., it is designed to attain the 
spacing goal at the achieve-by point, which in the NASA Airborne Precision Spacing concept is normally 
the runway threshold. The algorithm does not exactly obtain and maintain the spacing goal until the 
ownship is near the achieve-by point. Using this control method, the aircraft should be able to fly speeds 
that are closer to the nominal profile for a longer portion of the operation relative to a more stringent 
control method that would maintain a fixed spacing interval. 

ASTARll Algorithm Implementation 

The implementation of the ASTAR1 1 algorithm is comprised primarily of five major elements: 
trajectory computation, current trajectory state data computation, the calculation of the spacing interval, 
the speed control law, and speed change minimization. Details of these elements are provided in 
subsequent sections. 
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Trajectory Computation 

General 

For the prototype system developed at the NASA Langley Research Center, a standalone trajectory 
generator was developed to calculate a full 4D trajectory from a 2D path specification. Reference 11 
provides a description of this algorithm to include its input and output parameters. In ASTAR11, the 
trajectory definition begins with a simple, augmented 2D path definition, e.g., a traditional Standard 
Terminal Arrival Route (STAR) with a continuous connection to an instrument approach procedure, along 
with relevant speed and altitude constraints. The trajectory generator then computes a full 4D trajectory 
defined by a series of Trajectory Change Points (TCP's). This standalone approach was developed for two 
reasons. First, a near-term implementation separate from the flight management system (FMS) was 
considered to be more practical from a development and implementation cost perspective. Second, since 
ASTAR11 needs to calculate the trajectory for the TTF, the additional complexity of calcu lating the 
trajectory for the ownship was minimal. Neither of these reasons, however, would preclude use of the 
FMS for providing the ownship trajectory into ASTAR1 1 nor the use of a data linked estimated time of 
arrival (ETA) or TTG from the traffic aircraft. 

One of the major difficulties in computing a 4D trajectory involves the calculation of the length of the 
ground path during a turn. During turns in either the presence of winds or with a change in the specified 
speed, the turn radius is changed, which then affects the length of the ground path. This change in the path 
length can then affect the distance to a deceleration point, which then affects the turn radius calculation. 
To accommodate this interaction, the trajectory calculation uses a multi-pass technique in generating the 
4D path with the first pass generating a close approximation to the TCP's based on the computed ground 
speeds. The following iterations then use the input from the previous pass as a starting point to refine the 
solution. 

In conjunction with the basic 4D calculation, ASTAR11 preprocesses the trajectory input data 
depending on the situation. ASTAR11 may change the generic trajectory parameters relative to aircraft 
final approach speeds, initial cruise altitude and speed, differences between the predicted and actual top of 
descent point, and differences in wind forecast data. 

Final Approach Speed 

The use of an achieve -by algorithm coupled with the operational requirement to achieve a stabilized 
approach means that the algorithm must compensate for differences in the TTF's and the ownship's actual 
final approach speeds. Because of this requirement, ASTAR11 modifies each aircraft's trajectory data by 
substituting the individual aircraft's planned final approach speed for the trajectory's generic runway 
threshold crossing speed. By using the indiv idual aircraft's planned final approach speed, the TTG 
calculations explicitly compensate for the final approach speed differences between the spacing aircraft. 
In addition, there are sev eral different operational techniques used in determining where the f inal 
approach speed is achieved. In the generic case, the final deceleration starts at a point prior to the runway 
threshold such that the aircraft just achieves its final approach speed as it crosses the runway threshold. 
Since this baseline technique is not typical for transport aircraft approaches in that it does not provide for 
a stabilized approach, ASTAR1 1 provides two other options. These options are: 

• Begin the final deceleration at the waypoint just prior to the runway. This is typical for operations 
where the final deceleration starts at the final approach fix (FAF). 

• Begin a deceleration such that the aircraft reaches its final approach speed at a specific altitude, e.g., 
to beat the final approach speed at 1000 feet (ft) above the runway's elevation, which is also the 
minimum requirement for instrument approaches in transport aircraft (ref. 12). To support this option, 
a special waypoint is included in the trajectory input data and is placed between the runway threshold 
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and the FAF waypoint. Only the crossing altitude and crossing speed data are included in this special 
waypoint's data and the trajectory generator calculates its position on the horizontal portion of the 
path. 

A fourth option was considered, where the final deceleration starts at a point prior to the FAF such that 
the aircraft just achieves its final approach speed as it crosses the FAF. This option, however, is not 
implemented because transport category aircraft do not normally operate in this manner. 

Initial Cruise Altitude and Speed 

A second change that ASTAR11 may make to the ownship's orTTF's trajectory input data is to 
substitute the individual aircraft's actual cruise altitude and Mach for the initial, generic altitude and Mach 
specified in the basic augmented 2D path. This change will only occur at the initiation of a new 2D path 
and with the aircraft's current altitude and Mach matching a rel evant data set be ing provided to 
ASTAR1 1. That is, the current altitude and Mach of the aircraft must match a special cruise altitude and 
Mach data set being sent to ASTAR1 1. For the TTF, this special data set could be made available to the 
ownship via data link. 

Top of Descent Monitoring 

The FMS may calculate and the aircraft may fly from a top-of-descent (TOD) point that is appreciably 
different than the generic TOD estimated by the trajectory generator. Since this difference in the TOD 
point can introduce a significant error in the estimation of the aircraft's ground speed during this descent 
and therefore lead to a significant error in the aircraft's TTG, ASTAR1 1 monitors for the conformance to 
its TOD point. If the aircraft begins its descent from cruise before the point that ASTAR11 predicted, 
ASTAR1 1 will calculate the actual, current descent angle based on this actual TOD and the next altitude 
crossing restriction, replace the generic descent angle in the augmented 2D path data with this new value, 
and then recalculate the 4D path. A similar technique is used for a late descent except that ASTAR1 1 may 
recalculate the 4D path several times, depending on how far beyond the originally estimated TOD point 
that the actual TOD occurs. 

Recalculation of the Vertical Path 

Similar to the problem noted in the section Top of Descent Monitoring , if an aircraft is significantly far 
from its planned vertical path, then the difference between the pla nned ground speed and the actual 
ground speed can b e large. This difference in ground speed can then produce a significant error in the 
aircraft's TTG. Previous versions of ASTAR allowed the vertical path error, i.e., the difference between 
the planned altitude along the path and the aircraft's actual altitude at that horizontal position on the path, 
to reach 6,000 ft, at which time it was assumed that the planned path was no longer valid. 

In this version of ASTAR, once an aircraft reaches 4,000 ft of vertical path error, ASTAR will attempt 
to construct a new 4D path beg inning at a po int on the original path relative to th e aircraft's current 
position. Following this initial, vertical present-position waypoint, any downstream waypoint with an 
altitude constraint that is higher than the altitude of the initial waypoint will have that constraint deleted. 
The last test that is performed in this modification is to determine if the first altitude constraint following 
the initial waypoint can be met. If this constraint cannot be met using the original crossing angle, a new 
crossing angle is calculated based on a linear descent between the initial waypoint and the constraint, with 
this new angle then used in the subsequent 4D calculation. 

Wind Forecast Data 

The last modification that ASTAR11 may apply to the trajectory input data is to modify the original 
wind forecast data provided to the algorithm. Wind data into and within ASTAR1 1 is based on waypoint 
locations instead ofaty pical wind grid. It was assumed inthedes ign of ASTAR11 that a highly 


4 


developed wind forecast model could be used to p rovide vertical profile wind data at the waypoint 
locations. Of special importance to ASTAR11 would be the wind estimation at the altitude that the 
trajectory would be crossing the waypoint's position. It was assumed then that the externally provided 
waypoint wind data would provide reasonably accurate wind data that would bound th e expected 
waypoint trajectory crossing altitude. Up to 10 altitude -wind speed data sets (altitude, direction, and 
magnitude) per waypoint may be input into ASTAR11. From this initial, external input ASTAR11 may 
then provide both local and global modifications to the forecast wind data provided to the trajectory 
generator. 

While up to 10 altitude-wind datasets per waypoint may be input into ASTAR11, ASTAR11 itself 
maintains an internal wind model, with this wind model using data not only from the input waypoint wind 
data, but also aircraft-sensed, local wind data. This internal wind model maintains a 1000 ft incremental 
vertical profile, from 0 ft to 60,000 ft, f or every waypoint on all of the paths. This incremental vertical 
profile contains a "gain" value, the original input wind forecast for this altitude, a measured wind for this 
altitude, and the current estimated wind forecast for this altitude. Initially, the gain values are all set to 
zero. Initially, the external wind forecast is used to populate the input wind forecast for each altitude in its 
profile, with an altitude -based linear interpolation used to populate the altitudes that do not directly have 
any input value. 

Measured wind values may be adjusted using local or global data. For the local data case, the ownship's 
wind derivation is us ed to update the estimated wind forecast. In this case, wind profiles for every 
waypoint within 50 nautical miles (nmi) of the ownship's horizontal position may be modified. For these 
waypoints, if the ownship is at or above 12,000 ft, then each of the 1000 ft incremental vertical profile 
data sets may be modified for altitudes within ±5000 ft of the ownship's altitude. For the situation where 
the ownship is below 12,000 ft, then each of the 1000 ft incremental vertical profile data sets may be 
modified for altitudes within ±3000 ft of the ownship's altitude. Whether a specific 1000 ft incremental 
vertical profile data set is modified depends on the current gain value for that data set and the gain value 
computed for the current ownship's position relative to this data set, with the ownship's current gain being 
calculated as follows: 

x ownship = relative horizontal position of ownship (in nmi) to the wind profile point and 
z o W nship = relative vertical position of ownship (in ft) to the wind profde point. 

If township Is greater than 50 nmi, gain horizonta i = 0, 
otherwise gain horizonta i = 1 - (x ownship / 50 nmi). 

If z ownship Is greater or equal to 12,000 ft, then 

If z ownship is greater than ±5000 ft, gain vertica i = 0, 
otherwise gain vertica i = 1 - absolute value of (z ownship / 5000 ft), 
otherwise 

if Zownship is greater than ±3000 ft, gain vertica i = 0, 
otherwise gain vertica i = 1 - absolute value of (z ownship / 3000 ft), 
ownship's current gain = gain hor izontai * gain ver ticai • 
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If the ownship's computed gain is greater than the gain value for the data set, then the estimated wind 
data are updated with the new gain value and measured wind data. The new estimated wind data are 
computed based on a dou ble linear interpolation between the original forecast winds and the measured 
winds. The double linear interpolation uses the relative horizontal position, the relative vertical position, 
and the previously calculated, associated gain values. 

ASTAR11 has the option to include a global wind updating capability in its wind forecast update. In 
this case, ASTAR1 1 uses time correlated ADS-B state vector and air referenced velocity reports from all 
surrounding aircraft to generate a local wind estimate at each aircraft’s position. The estimated wind 
forecast is then updated in the manner previously described. 

To exclude erroneous measured wind values which can typically occur when an aircraft is turning, a 
simple track-file for each aircraft is maintained for each aircraft's true ground track. If this ground track 
value is changing, based on the aircraft's current and previous track angle values, the aircraft's wind data 
are excluded from the wind forecast update. In other words, if an aircraft is turning, its wind estimation 
would not be used in the internal forecast. 

Once anewint emal forecast has been g enerated, ASTAR11 selects the best altitudes for each 
waypoint, based on bounding the trajectory crossing altitude, to update the wind data profile in the 
trajectory input data. To determine if a new trajectory calculation is required due a change in the forecast 
wind data, a w aypoint-by-waypoint comparison between the wind data profiles of the current trajectory 
wind data and th e internal forecast data is pe rformed. If there is a significant difference between these 
data sets, then the trajectory profile wind data are updated using the internal wind forecast data and a 
trajectory recalculation is then performed. The determination of a significant difference between these 
data sets is based on the following calculation for each wind-altitude point in the trajectory: 

if the difference in wind speed is greater than the variable “s ”, then the difference is significant 
or 

if the wind speed of the trajectory data is greater than s and the difference in wind angle is 
greater than the variable (( a ”, then the difference is significant, where 

if the distance to go for the ownship, DTG ownship , is greater than 200 nmi, s = 5 kts and a = 10°, 

otherwise if DTG owns hi P is greater than 20 nmi, s = 3 kts and a = 5°, 

otherwise s = 1.5 kts and a = 5°. 

Trajectory State Data Computation 

The trajectory state data are the trajectory data, e.g., altitude, CAS, ground speed, and ground track, at 
a point on the trajectory. By design, speed and altitude changes occur linearly between TCP's as defined 
by the trajectory generator. Because of this, the determination of a trajectory state based on an aircraft’s 
position is reasonably easy to calculate. First, the determination of the relative segment, i.e., between 
which two TCP’s does the aircraft's position lie, must be calculated. For the example of figure 2, TCPi is 
the first TCP on the trajectory, which is typically a high-altitude, cruise waypoint, and TCP n is the last 
TCP, which is typically the runway threshold. Beginning with the first TCP segment, i.e., the segment 
defined by the TCP pair TCPi and TCP 2 , a determination is made if the aircraft's position lies angularly 
between the two TCP's and if so, is the orthogonal distance (fig. 3) between the aircraft's position and that 
segment a minimum for the trajectory? In this example, the aircraft is forward of TCPi (fig- 4), in the 
direction of the trajectory's ground path, and behind TCP i+ i (fig. 5). 
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Figure 2. Trajectory state estimation. 


Figure 3. Orthogonal distance measurement. 



The trajectory state distance, i.e., the distance-to-go (DTG), is then simply calculated from the distance 
to TCPi+i (DTGi+i) plus the relative distance between TCP i+ i and the projection of the position unto the 
segment (this relative distance is shown as d in figure 6). The trajectory altitude is then computed using a 
simple linear interpolation between the distance between the trajectory state point (d in figure 6) and 
TCPi+i and the distance between TCPi and TCP i+ i, i.e., DTGi - DTG i+ i. For example, the altitude (alt) at a 
position p d on the trajectory can be calculated as: 

x = d/( DTGt - DTG i+1 ) 

alt d = x * alti + (1 - x) * alt i+1 



Figure 6. Distance-to-go measurement. 
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Since speed changes are constant between TCP's, the trajectory state speeds and time at p d may be 
calculated using the linear equations of motion. For example, the CAS at p d , CAS d , may be calculated as 
follows: 


CAS d = square root (x * CAS? + (1 - x) * CAS i+1 2 ) 

The determination of the trajectory state from the TTG can be computed using a similar technique. 

Calculation of the Spacing Interval 

The spacing interval provided by ATC may be given to ASTAR1 1 in either time or distance. An 
explanation of these two spacing interval types is provided in the following two sections. 

Basic Time Interval 

The basic time spacing interval is the interval that ATC would assign for the spacing aircraft to obtain 
at the runway threshold against the assigned TTF. The basic spacing interval for ASTAR11 is a time- 
reference interval against a TTF that is landing on the same runway as the ownship. The operational goal 
in this situation is for the ownship to cross the runway threshold at the assigned interval after the TTF 
crossed the same threshold. For this basic time interval case, there is no additional calculation required for 
the spacing interval; it is simply the time assigned by ATC. 

Basic Distance Interval 

In the basic distance spacing interval case, the operational goal is for the ownship to be at the ATC 
assigned distance behind the TTF just as the TTF crosses the runway threshold. As in the basic time 
interval case, the same runway is used by both the TTF and the ownship. For this case, the applicable 
spacing time that is used by the control law can be calculated from the 4D trajectory by determining the 
ownship’ s trajectory state at the assigned spacing interval distance-to-go from the threshold. The spacing 
time goal is then the time-to-go to the threshold at this distance. That is, the relevant spacing time is the 
time-to-go on the ownship's trajectory at a distance-to-go equal to the assigned spacing distance. 

Achieve-By and Termination Point at the Final Approach Fix 

For the normal situation where the achieve -by point is the runway threshold, the use of an achieve -by 
algorithm coupled with the operational requirement to attain a s tabilized approach means that the 
algorithm must compensate for di fferences in the TTF's and the ownship's actual final approach speed 
prior to the stabilized approach point. This capability is implicitly provided by the use of the respective 
aircrafts' final approach speeds in the calculation of their trajectory times to the runway threshold. For the 
situation where the achieve -by point is the final approach fix, then the algorithm offsets the aircrafts' TTG 
value by the time difference between the time to the runway threshold and the time to the FAF. 

If the termination point is the FAF, as it is for ATD-1, once the traffic aircraft crosses the FAF, the 
adjusted spacing time interval for figure 7 is then calculated as: 

adjusted spacing time interval = 

adjusted spacing time interval origina i - (current time - FAF crossing time T TF ), 

where the adjusted spacing time interval origina i is the orig inal ATC assigned spacing interval along with 
any other adjustments, e.g., runway offset, and FAF crossing time TTF is the time that the TTF crossed the 
FAF. Note that in the subsequent calculation of the nominal spacing time that the value for the TTG T tf 
(fig. 7) is set to zero. A similar technique can be used in the spacing distance calculations. 
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Speed Control Law 

The use of the trajectory calculations in the speed control law is relatively straightforward. The time 
error term calculation described previously, 


terror TTG ownship t nom i na i 


is then used in the speed control law (fig. 7). The overall design concept for this control law was to 
command the nominal trajectory speed with any resulting spacing error only modifying this nominal 
speed by a maximum of ±10%, thus providing some level of speed predictability to the flight crew and to 
ATC. This technique also eliminates the unbounded speed command problem noted in reference 13. 



(from Ownship trajectory state) 


Figure 7. Speed control law. 

The value of gi (fig. 8), which is used to gain schedule the speed error term, is: 

if DTG ownship is greater than 100 nmi, gi = 0.375, 

otherwise if DTGownship is greater than 40 nmi, 

g! = 0.375 + 0.125 * (100.0 - DTGownship) / 60.0, 

otherwise if DTGownship is greater than 25 nmi, 
gl = 0.5 + 0.5 * (40.0 - DTGownship) / 15.0, 

otherwise if DTGownship is greater than 10 nmi, 
g j = 1.0 + 0.5 * (25.0 - DTGownship) / 15.0, 

otherwise g! = 1.5. 
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Figure 8. Gain schedule, gi. 


The value of g 2 is 0.1. This limit filter limits the speed-error value to ±10% of the ownship's nominal 
trajectory speed. At 10 nmi, these values produce 1.5 kt of speed correction (fig. 7) for one second of time 
error. 

For the case of the RTA, the nominal spacing time is simply: 

t nominal = RTA - current time 

where this value is substituted for the nominal spacing time from the TTF data in figure 7. 

Because the ope rational envelop for th is algorithm includes high altitude Mach portions, both t he 
trajectory calculations and the control law accommodate Mach. If the aircraft is operating in a Mach 
regime, then the Mach value from the trajectory data, converted to CAS, is used in the control law. The 
commanded CAS from the control law is then converted to a Mach command for output. 

Finally, there comes a point on final approach when the ownship needs to decelerate to its final 
approach speed and speed changes to correct spacing errors are no 1 onger appropriate. The earlier 
subsection titled ‘Final Approach Speed’ describes the two typical operational techniques for terminating 
active spacing and transiting to the aircraft's planned final approach speed. An example of how this 
capability is supported in ASTAR1 1 is shown in figure 9. In a purely nominal situation, i.e., where there 
was no spacing error, the speed command would simply follow the nominal trajectory speed profile with 
the deceleration to the aircraft's final approach speed beginning at the nominal point on the trajectory. If 
the commanded speed w ere faster than the nominal speed (fig. 9), then th e deceleration to th e final 
approach speed would need to occur earlier. To accommodate this situation, ASTAR1 1 projects the final 
approach speed deceleration backwards from the nominal beginning of the final deceleration segment. 
Once the commanded speed point intercepts this deceleration line, ASTAR11 transitions into a final 
speed mode and provides a speed command that equals the appropriate speed along this deceleration line. 
An analogous technique is used for the situation where the commanded speed prior to the final 
deceleration is slower than the nominal speed (fig. 10). In this case, ASTAR1 1 would again maintain the 
original commanded speed until the commanded speed point intercepts this deceleration line, with the 
intercept point being after the nominal beginning of the deceleration segment. 
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Projection of the final approach speed deceleration 

, Nominal beginning of final approach speed deceleration 
, Final approach speed deceleration 
.Final approach speed 



Current commanded speed 
(faster than nominal) 


Nominal trajectory speed profile 


4 

Runway threshold 


Figure 9. Final approach speed deceleration from an initially faster commanded speed. 



Figure 10. Commanded speed-profile from an initially slower commanded speed. 


Speed Change Minimization and Lag Compensation 

One of the most significant design requirements for the last two versions of ASTAR is the ability to 
support a low cost, aircraft retrofit option with very minimal integration with other aircraft systems. In 
this option, it was assumed that the speed command value would be presented to the pilot and the pilot 
would then change the speed target of the autothrust system to match the commanded speed from ASTAR 
or, less likely, directly track the speed command through manipulation of the thrust levers. While this 
option is probably less than ideal from both a human factors and speed tracking performance perspective, 
there has been interest from the aviation community in providing a relatively low cost option (ref. 14) for 
airborne self-spacing. To support this option, from a pilot workload standpoint it was deemed beneficial 
to attempt to minimize the number of speed command changes presented to the pilot. Several capabilities 
are provided within the algorithm that attempt to balance the number of speed changes against the spacing 
performance. The implementation of these capabilities has led to a considerable increase in complexity of 
the ASTAR1 1 algorithm. 

Error Gain Scheduling 

One means for reducing the number of speed changes in a spacing algorithm is to notch filter the time 
error value prior to its use in the speed command calculation. By notch filtering, fairly large errors are 
allowed when far from the runway threshold without inducing a speed correction. This technique was 
used in ASTAR10. One significant performance issue with using a notch filter is that by allowing large 
spacing errors when far from the runway, the algorithm may not be able to recover from what may have 
been a recoverable error. For example, if the aircraft were initially situated without any spacing error and 
the TTF then flew the approach as fast as possible, i.e., the profile speed plus 10 percent, then the 
following would occur: 

• The ownship would continue to move farther behind the nominal spacing interval until the notch 
filter limit was reached. 

• Once the notch filter's limit was reached, ownship's speed command would increase until the 
speed command reached the profile speed plus 10 percent. 
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• The ownship would maintain the spacing error that was present when the ownship's speed 
command reached the profile speed plus 10 percent. 

Based on some unsatisfactory performance issues when using this notch filter technique (ref 15), a 
simple speed error gain schedule, gi in figures 7 and 8, is now used in the speed control law for 
ASTAR11. 

End Speed Estimation 

In this implementation of ASTAR, the pilot is expected to implement the algorithm's speed command 
by matching the aircraft's autothrust command to the ASTAR speed command. During a programmed 
deceleration segment without any spacing error, e.g., a change in the nominal speed profile from 210 let to 
170 kt (fig. 11), the ASTAR speed command would change continuously during the deceleration 
segment, with the command speed following the nominal speed profile. To reduce pilot workload so that 
the pilot did not need to continuously monitor the speed command and continuously change the input to 
the autothrust system, a secondary speed command is output by ASTAR for display to the pilot. This 
secondary speed command, termed the end speed command, is an estimate of the speed command at the 
end of the speed change. In the example of figure 1 1, the end speed command would change from 210 kt 
to 170 kt as the aircraft reaches the start of the 210 to 170 kt deceleration segment. For long deceleration 
segments, the end speed command could be used first by the pilot to set the autothrust speed target and 
then the basic, instantaneous speed command could be used to modulate the thrust or aircraft's drag 
devices to better follow the decelerating speed command profile. 



Figure 11. Example speed change with no spacing correction. 

A similar situation would occur in the presence of a required speed correction due to a spacing error or 
RTA adjustment. In figure 12, the nominal speed profile is the same as in figure 11, but there is now a 
positive 10 kt spacing correction. Prior to the start of the nominal 210 to 170 kt deceleration segment, 
both the speed command and the end speed command would be 220 kt. At the start of the deceleration 
segment, the speed command would be 220 kt while the end speed command would change to 180 kt. 
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Distance-to-go (DTG) (nmi) 

Figure 12. Example speed change with a positive lOkt spacing correction. 


Speed Command Quantization 

Another means for reducing the number of speed changes in ASTAR was to use a quantization 
technique on the end speed command and, except during speed changes, on the instantaneous speed 
command. By applying a quantization to the speed command prior to its output, the end speed command 
changes would only occur in discrete intervals, thus reducing the number of commanded speed changes. 
For example, if the speed command (fig. 7) was to change from 210 kt to 172 kt and a 5 kt quantization 
value was used, then the following would occur: 

• Immediately prior to the speed change, the output values for both the speed command and the end 
speed command would be 210 kt. 

• At the start of the speed change, the output value for the speed command would slowly begin to 
decrease, e.g., 209, 208, 207 kt. The output value for the end speed command, because it is being 
’’chunked” in 5 kt increments by the quantization process, would change to 170 kt. 

• At the end of the speed change, the output values for both the speed command and the end speed 
command would be 170 kt. 

Hysteresis was included in the quantization logic to reduce dithering of the end speed command when the 
command speed is near the breakpoint for the quantization value. 


Nominal Deceleration Roll-In Logic 

During the initial evaluation of ASTAR10 (ref. 15), it was determined that the lag in response to a 
speed command change by the simulated aircraft was problematic and contributed to undesirable spacing 
performance, especially under situations where several aircraft were spacing one after another, i.e., a 
spacing string. To reduce this problem at the start of a planned deceleration segment in the nominal 
profile, where this response lag was most apparent, predictive, nominal speed roll-in logic was added to 
the speed command. An example of a deceleration in the nominal profile without this roll-in logic is 
shown in figure 13. In this example, there is no speed error, so the instantaneous speed command would 
match the nominal speed profile. Additionally, the change in the end speed command would occur at the 
deceleration point on the nominal speed profile. Therefore, at 300 seconds TTG in the example of figure 
13, the end speed command would change from 210 kt to 170 kt and the instantaneous speed command 
would begin to decrease at a rate equal to the change in the nominal speed profile. Using a 12 second look 
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ahead, the equivalent situation is shown in figure 14 with the roll-in logic. In figure 14, the end speed 
command would change from 210 kt to 170 kt 12 seconds earlier relative to the basic profile. In this 
situation (fig. 14), the instantaneous speed command would change in a manner such that the nominal 
deceleration rate and speed would just match the nominal command speed and deceleration rate 24 
seconds after the start of the roll-in period. 


Nominal speed profile 



Time-to-go (TTG) (sec) 

Figure 13. Nominal speed change without roll-in logic. 


Nominal speed profile 



Figure 14. Nominal speed change with roll-in logic. 


Look Ahead Speed Change Inhibit 

To minimize the number of speed changes prior to a programmed deceleration segment, i.e., where the 
planned trajectory specifies a deceleration, a look-ahead speed change inhibit option was used. In this 
regard, the algorithm would look ahead by 10 seconds in the nominal speed profile (fig. 15) to determine 
if a change onto a deceleration segment would occur. Within this 10 second interval, any speed command 
increase would be inhibited. If the nominal deceleration roll-in logic, described in the previous section, is 
used, its 12 second roll-in interval would be added to the 10 second look-ahead interval. Thus, the speed 
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change inhibit logic would be applied 22 seconds prior to the deceleration point on the basic, nominal 
speed profile. 


Nominal speed profile 


10 sec look-ahead 



Figure 15. Look-ahead speed-up inhibit. 

Operational Considerations 

Common Speeds After Merging 

The potential for the loss of separation or less than operationally desirable separation distances between 
the ownship and the TTF can be minimized by the design of the speed profiles on the respective 2D paths. 
In this regard, the speeds specified in the path definitions at and after the point where the paths join in the 
horizontal plane must be the same speeds (fig. 16). That is, common path points must have common 
speeds. 



Start of TTF' s 


path 



Merge point 


Co m mo n speed from 
here to the runway 


Figure 16. Example of common speeds after the merge point. 


Envelope Protection 

Since the speed command value from ASTAR1 1 could be used to directly drive an autothrust system, 
speed envelope limiting can optionally be prov ided by the alg orithm. To in voke this f eature, the 
maximum and minimum desired speed values, both Mach and CAS, are input into ASTAR11. These 
input limit speeds are usually based on the design limiting speed, the maximum gust penetration speed, 
the maximum flap extend ed speed, and m inimum maneuvering speed. The algorithm then lim its the 
command speed to remain within these values. When the command speed is limited, the algorithm sets an 
output flag indicating this limiting condition. 

Off-Nominal Mach / CAS Transition 

The algorithm provides both Mach and CAS speed command values and a Mach/CAS flag indicating 
which of th ese values, Mach or CA S, is appro priate for u se relative to the aircraft's current flight 
conditions. While the 4D trajectory data provides the nominal altitude value for the Mach to CAS 
transition, this altitude value is only valid if the aircraft is exactly on the planned vertical path from the 
4D trajectory and is at the nominal Mach. Because these conditions are not generally true, e.g., the Mach 
speed command is slower than the nom inal value to correct a spacing error, ASTAR11 computes the 
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Mach to CAS transition altitude for the current commanded speeds. Once the aircraft descends below this 
altitude, the algorithm transitions to a CAS command for the remainder of the operation. 

Landing of the Traffic to Follow Aircraft 

If the ow nship has not reached its final deceleration point prior to the TTF crossing the runway 
threshold, ASTAR will continue to correct for spacing errors even after the TTF has crossed the runway 
threshold. To continue actively spacing after the TTF crosses the threshold, the algorithm “freezes” the 
TTF’s state data, i.e., time and position, just as the TTF crosses the threshold. The algorithm then offsets 
the spacing time interval by an amount equal to the current time minus the time that the TTF crossed the 
threshold. The adjusted spacing time interval for figure 7 is then: 

adjusted spacing time interval = 

adjusted spacing time interval origina i - (current time - crossing time T TF ), 

where the adjusted spacing time interval 0 riginai is the original ATC assigned spacing interval along with 
any other adjustments, e.g., runway offset, and crossing time T TF is the time that the TTF crossed the 
runway threshold. Note that in the subsequent calculation of the nominal spacing time that the value for 
the TTGttf (fig- 7) is zero. 


Future Design Considerations 

Even with the design requirement to support a low cost, aircraft retrofit option with very minimal 
integration with other aircraft systems, several modifications could be made to ASTAR11 to reduce its 
design and implementation complexity along with supporting greater operational viability. Two of these 
modifications involve the calculations for the trajectory data and the third modification involves the speed 
command limiting, lag compensation, and output quantization. 

Estimated Time of Arrival Data from the Traffic to Follow 

In ASTAR1 1, the assumption is that the TTF may only need minimal equipment, or possibly no extra 
equipment beyond ADS-B Out, to support airborne self-spacing. It was assumed that a normal self- 
spacing operation would start prior to the top of descent and continue through the start of the ownship’s 
deceleration to its final approach speed. To compute the trajectory data for the TTF, the ownship would 
need for the TTF: the names describing its full path, i.e., arrival, transition, and approach names; its cruise 
Mach and altitude; and its planned final approach speed. It is also assumed that a data base that is either 
local to or part of the ASTAR equipment would interpret the names describing the full path into data that 
are appropriate for the ASTAR trajectory computation. If these data required to calculate the TTF 
trajectory are not available via data link, then other means for obtaining these data, or eliminating the 
need for these data, must be found. 

Regardless of how these path data are obtained, the trajectory data calculated for the TTF is only a 
generic ’’guess” on how the TTF will actually fly the route. Discrepancies between the ASTAR trajectory 
calculation for the TTF and how the TTF actually flies the route, typically dictated by the FMS, would be 
propagated in ASTAR as a spacing error. One obvious option for eliminating much of this particular error 
would be for the TTF to broadcast via data link its ETA, i.e., its TTG. This broadcast could be done at a 
low frequency, e.g., once every 30 seconds, since the ETA value would typically not change very rapidly. 
This option would also eliminate the data requirements to the TTF’s trajectory generation that were 
described in the previous paragraph. However, this option would require that the TTF have the ability to 
generate an accurate ETA and, obviously, the ability to data link this information. 
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Trajectory Data from the Ownship FMS 

Similar to the issues and benefits for using the TTFs ETA data from a data linked, FMS source, the use 
of the ow nship's FMS data could significantly reduce the complexity of the spacing algorithm and 
increase its operational viability. The first obvious option in this regard would be to use the ow nship's 
FMS ETA data in place of the ASTAR trajectory TTG. While this option may provide a more accurate 
TTG value, it still requires ASTAR to calculate a trajectory for the nominal speed values. As a second 
option, if the FMS could provide the ETA and the current, non-RTA nominal speed values, then ASTAR 
would not need to calculate a trajectory for the ownship. The most extensive option for reduction in 
ASTAR's complexity would come if the speed error value in figure 7 could either be used as an input to 
the FMS speed requirements, e.g., to adjust the next waypoint crossing speed, or superimposed on the 
FMS speed output command. Alternatively, the sp acing time error value could be used to calculate a 
pseudo RTA value and this RTA value input into the FMS. 

Speed Prediction, Speed Quantization, and Lag Compensation Functions 

Many of the ancillary functions in ASTAR1 1, e.g., the autothrust lag compensation, were added to the 
implementation ad hoc to overcome operational or p erformance issues that were observed prior to and 
during simulation evaluations. As such, the overall design for the numerous functions that were added for 
a non-integrated, aircraft r etrofit application along with functions to compensate for the aircraft speed 
response to speed command changes, e.g., the autothrust lag compensation, was not a design "in the 
large." It would be b eneficial for both the simplification of the algorithm and po tentially better 
operational performance if these functions could be consolidated into one or two coherent functions. 

Summary 

This paper provides an overview of the Airborne Spacing for Terminal Arrival Routes (ASTAR) 
algorithm. This algorithm is a trajectory-based, self-spacing tool using ADS-B data from a leading aircraft 
assigned by ATC to the following, self-spacing aircraft. This fourth revision of this algorithm was tailored 
toward supporting the Air Traffic Management Technology Demonstration- 1 (ATD-1) and pi aces 
significant emphasis on providing a low cost, aircraft retrofit option with very minimal integration with 
other aircraft systems. In this option, it was assumed that the speed command value would be presented to 
the pilot and the pilot would then change the speed target of the autothrust system to m atch the 
commanded speed from ASTAR. Several capabilities are provided within the algorithm that attempt to 
balance the number of speed changes against the spacing performance. In addition to describing the 
trajectory computations, spacing interval calculations, and the speed control law, this paper also discusses 
operational issues that were addressed in the development of this tool. 
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